home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL96.LZH / t0130 / text0003.txt < prev    next >
Encoding:
Text File  |  1996-03-07  |  3.6 KB  |  92 lines
  1. > > If somebody can find a useful description of the formulae and approach 
  2. > > employed by Doom to deal with this problem, then I will be happy to replace
  3.  
  4. I'd be very surprised if it was possible to (legally) get any information
  5. on how DOOM deals with things from a technical point of view.
  6. Id Software, very likely, have released all information they're going to.
  7.  
  8. > > my code with a DSP version of those routines. Until then I'm hanging onto
  9. > > the source.
  10.  
  11. Just let the rest of us programmers know what, exactly, it is you want
  12. code for and it'll be written.
  13. The whole point of this project is to have a _team_ creating this thing.
  14. If you have some code you don't want to use, then release the rest of it
  15. and tell us what's missing.
  16.  
  17. Doug mentions in his letter that I've held back sources myself, which is
  18. partly true (the assembly chunky to planar routine), but then I, naturally,
  19. supplied other code that did the same thing.
  20. The difference is that my sources are always available for use in other
  21. FreeWare (or similar) programs, which is an important distinction.
  22.  
  23. I even asked Doug once if he wanted the code for his free APEX viewers, but
  24. he declined, preferring his own DSP code instead. In his place, I would of
  25. course have done the same, since for me it's the programming that's the
  26. main point, not the end result.
  27.  
  28. > Okey. We have got two options.
  29. > 
  30. > 1) We go along with Doug's whishes (not good, but it makes sense) and
  31.  
  32. It only makes sense if we regard this as a project to create a game as
  33. quickly as possible. I do not at all agree with that view.
  34.  
  35. As a programmer, my first interest is the development of the engine. If
  36. something playable comes out of it thats very nice, but not the main point.
  37.  
  38. >    use his black box that will probably be faster than using the 
  39. >    "correct" method. 
  40.  
  41. But unfortunately, we would not be able to test that, lacking the sources.
  42.  
  43. > 2) Maybe we can use parts from the french doom clone and let Doug do
  44.  
  45. Did those people get on the list?
  46. Anyone know anything more about what they have to say?
  47.  
  48. >    an DSP version of that (it looks like it uses the "correct" method).
  49.  
  50. I must say I still haven't understood what it is Doug's referring to.
  51. At first I thought he ment the perspective correction needed to make
  52. textures look right at a distance as for the walls and floor/ceiling in the
  53. following 'room':
  54.  
  55. \             /
  56.  \           /
  57.   \         /
  58.    \-------/
  59.    |       |
  60.    /-------\
  61.   /         \
  62.  /           \
  63.  
  64. but the maths for that are pretty simple and optimisations to it have been
  65. discussed to death on rec.games.programmer and elsewhere.
  66.  
  67. If that's not it, I have no idea what he's talking about.
  68. If that _is_ indeed the problem, we have just proved that a team effort is
  69. much preferable to someone working alone.  ;-)
  70.  
  71. (By the way, if I understood you correctly on the phone Magnus, that's
  72.  probably what those square roots were for.)
  73.  
  74. >    will lose a lot of time (time isn't the problem here) but we will
  75. >    have an version with sourcecode.
  76.  
  77. Exactly my view!
  78.  
  79. > As Johan said in another letter maybe we realy should discuss the legal
  80. > status of Bad Mood. One option is to include the source for those parts
  81. > there the author say it's okey and leave out some black boxes if he 
  82. > doesn't want to release it. Not good, but better than nothing.
  83.  
  84. IM(NS)HO it's _not_ better than nothing.
  85.  
  86. -- 
  87.   Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
  88.      of Technology      |  .signatures  |            johan@rand.thn.htu.se
  89.                         | so hard to do |  WWW/ftp:  rand.thn.htu.se
  90.    Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)
  91.  
  92.